home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20031118-20041115
/
000030_slash_dev_slas…_2000@yahoo.com_Tue Dec 2 09:30:17 2003.msg
< prev
next >
Wrap
Internet Message Format
|
2004-11-14
|
4KB
Path: newsmaster.cc.columbia.edu!panix!news.maxwell.syr.edu!postnews1.google.com!not-for-mail
From: slash_dev_slash_null_2000@yahoo.com (Mark Sapiro)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problem in Kermit trying to get a file while sending it at the same time
Date: 1 Dec 2003 16:13:25 -0800
Organization: http://groups.google.com
Lines: 65
Message-ID: <deb126db.0312011613.1b889e6f@posting.google.com>
References: <f0bb0f39.0311250532.1b93aad@posting.google.com> <slrnbs6r9i.oig.fdc@sesame.cc.columbia.edu> <f0bb0f39.0311260731.11d9eb29@posting.google.com> <f0bb0f39.0311261025.6fd175b5@posting.google.com> <slrnbsa0at.dm1.fdc@sesame.cc.columbia.edu> <f0bb0f39.0312010625.7751d0a7@posting.google.com>
NNTP-Posting-Host: 209.182.169.133
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1070324006 11751 127.0.0.1 (2 Dec 2003 00:13:26 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 2 Dec 2003 00:13:26 +0000 (UTC)
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14706
anthonypieper@cs.com (newexpectuser) wrote in message news:<f0bb0f39.0312010625.7751d0a7@posting.google.com>...
> I think I understand the following in the article:
>
> "Notice that failure leaves the partial file (if any) in the working
> directory, where the central-site watcher process does not look for
> it. Thus transient failures do no harm. The script can be run again
> later.
>
> The /DELETE switch on the PUT command removes the source file after,
> and only if, it was uploaded successfully; this prevents it from being
> uploaded again (you could also have it moved or renamed). This way,
> even if the script is run again for the same file, it will fail
> immediately because the file is no longer there. Or, if a file of the
> same name is in the same place, it is a new file that should be
> uploaded.
>
> Now we can move the uploaded file from the server's working directory
> to its ready directory (the syntax assumes a UNIX-like file system on
> server):
>
>
> ftp rename \m(nameonly) ../ready/\m(nameonly)"
>
>
> This solves my problem if I have a partial file, it will be transfered
> into a directory (working) where my central-site server won't be
> looking for it. Once this file has been dropped off 100%, then the
> next time around I run to send files, I will then pickup a full file
> in my working directory.
>
> What I don't understand is with the above "ftp rename \m(nameonly)
> ../ready/\m(nameonly)", how does this avoid moving the partial file
> from the working directory to the ready directory, there will still be
> a file in the working directory albeit a partial file and this command
> will move it along to the ready directory.
Both Frank and Jeffrey have been responding to your questions and have
really already provided the answers to the above, but I have a sense
that you still don't get it, so here's a shot at what I think the
confusion is.
Partial files occur in two ways. One way is that a transfer is
interrupted because of a communications error, a disconnect or
whatever. This may leave a partially transferred file on the
receiver. The material you quote above is dealing with this situation
and here the sender deals with it by transferring the file to a
"working" directory, testing this transfer (with "if failure" or "if
success") and only after successful complete transfer, moving the file
on the receiver to the "ready" directory.
The other kind of partial file that I think you're concerned about is
a file that is in the process of being written by some other process
when the sender considers it as a candidate for transfer. In this
case, it is up to the underlying operating system to either hide the
presense of the partial file until the creating process is done with
it, or to deny access to the file by another process until the
creating process in done with it. All real operating systems do this.
If the process that is creating this candidate file is a file
transfer process that could actually terminate before the file is
complete, then it too needs to use a "working directory"/"ready
directory" scheme.
--
Mark Sapiro msapiro -at- value net The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan